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L Real Party in Interest (37 CFR §41.37(c)(l)(i)) 

The real party in interest is Secure Electrans Limited, who is the assignee of the application 
as per an assignment recorded at Reel 012135, Frame 0212. 

2, Related Appeals and Interferences (37 CFR §41.37(c)(l)(ii)) 

There are no related appeals and interferences. 

3, Status of Claims (37 CFR §41.37(c)(l)(iii)) 

Claims 1-21, 23-26, 28, 37-39, 41-43, and 45-48 are pending. 
Claims 22, 27, 29-36, 40, and 44 have been canceled. 

Claims 1-21, 23-26, 28, 37-39, 41-43, and 45-48 stand rejected under 35 USC § 103(a). 
Claim 45 stands rejected under 35 USC §101. 

All pending claims (1-21, 23-26, 28, 37-39, 41-43, and 45-48) are appealed. 

4 Status of Amendments (37 CFR §41.37(c)(l)(iv)) 

No claim amendments have been filed subsequent to the April 6, 2010 Final Office Action. 

5, Summary of Claimed Subject Matter (37 CFR §41.37(c)(l)(v)) 

Appealed independent claims 1, 28, 37, 42, 43, and 45-47 relate to systems and methods for 
reducing credit / charge card fraud by verifying, in the course of a credit / charge card transaction, 
that a card is physically present at or near the location of a utility meter (which is identified by, e.g., 
a utility meter serial number). Because utility meters are installed in known locations, a transaction 
request submitted at or near a utility meter identifies the location of the submission to a high degree 
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of certainty. For example, a credit / debit card charge request may be transmitted (such as via phone 
or Internet) to a financial institution wherein the request includes (1) an identifier of a nearby meter; 
(2) the credit / charge card data (e.g., account number); and (3) "card presence" data (data verifying 
that the credit / charge card is physically present at the location of the charge request, such as a 
physical card swipe and/or entry of the 3-digit "CVV" code on the card signature strip). Thus, the 
financial institution is given some degree of assurance regarding the charger's location (and the card's 
location) because it is associated with a utility meter location, thereby allowing differentiation 
between "valid" charges and those from (for example) overseas submission of stolen card data. Most 
of the present claims also include limitations to the effect that the credit / debit card charge request 
is generated and/or processed regardless of whether the charge request relates to any utility usage 
measurements made by the utility meter - in other words, the invention can be used to verify the 
location of any type of charge card transaction (such as online or retail purchases of goods), and is 
not limited to utility purchases associated with readings from the meter. 

Reviewing each of the independent claims specifically, with reference to the specification: 
CLAIM 1 is directed to a financial transaction authorization system (page 3 lines 3-21) 
comprising: a financial institution (page 2 lines 2-4, item 40 in FIGS. 2, 4-7) which processes credit 
/ charge card charge requests (page 2 lines 11-14, page 3 lines 8-9) ; a utility meter (item 1 0 in FIGS . 
1-7, items 50, 60 in FIGS. 4-7) provided at a meter location separate and spaced from the financial 
institution (page 3 lines 1 1-12), the utility meter having an associated meter location identifier unique 
to the meter location (page 3 lines 5-6); and a user interface unit (item 30 in FIGS. 1-7) separate and 
spaced from the financial institution, the user interface unit being adapted to process a submitted 
credit / charge card charge authorization (page 4 lines 19-21). The utility meter is arranged to 
communicate with the user interface unit (page 3 lines 6-7); to obtain the card charge authorization 
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therefrom (page 3 lines 7-8); and to transmit a credit / charge card charge request to the financial 
institution based on the card charge authorization and meter location identifier (page 3 lines 8-9), the 
card charge request including data identifying a credit / charge card account (page 3 lines 15-18, page 
8 line 27 to page 9 line 3), and data verifying that the credit / charge card corresponding to the credit 
/ charge card account is physically present at the location of the user interface unit (page 3 lines 
15-18, page 8 line 27 to page 9 line 3). The utility meter is also arranged to obtain authorization of 
the card charge from the financial institution (page 8 line 3 to page 9 line 19), wherein the financial 
institution processes the card charge request from the utility meter regardless of whether the card 
charge request relates to any utility usage measurements made by the utility meter (page 3 lines 3-21). 

CLAIM 28 is directed to a method of authorizing a card financial transaction (page 3 lines 
3-21) comprising the steps of: providing a user interface unit at a location (item 30 in FIGS. 1-7); 
providing a utility meter at the location (item 10 in FIGS .1-7, items 50, 60 in FIGS . 4-7, page 3 lines 
11-12), the utility meter having an associated meter location identifier uniquely identifying the 
location (page 3 lines 5-6); accepting a card charge authorization request via the user interface unit 
(page 8 line 21 to page 9 line 3), the transaction authorization request including data verifying that 
a credit / charge card is present at the location of the user interface unit (page 3 lines 15-18, page 8 
line 27 to page 9 line 3), and data identifying the credit / charge card account of the credit / charge 
card (page 3 lines 15-18, page 8 line 27 to page 9 line 3); communicating the card charge 
authorization request from the user interface unit to the utility meter (page 3 lines 6-8); and 
transmitting a message generated in dependence on the card charge authorization request and meter 
location identifier from the utility meter to a financial institution to obtain authorization of the card 
charge (page 3 lines 8-9, page 8 line 3 to page 4 line 19) The financial institution processes the 



-4- 



message regardless of whether it relates to any utility usage measurements made by the utility meter 
(page 3 lines 3-21). 

CLAIM 37 is directed to a credit / charge card financial transaction authorization system for 
card charge transactions where the cardholder is at a location remote from the vendor (page 3 lines 

3- 21), the system comprising: a user interface unit (item 30 in FIGS. 1-7) capable of accepting card 
charge data including credit / charge card data identifying a credit / charge card to be charged (page 
3 lines 15-18, page 8 line 27 to page 9 line 3), and data verifying that the credit / charge card is 
physically present at the user interface unit (page 3 lines 15-18, page 8 line 27 to page 9 line 3); a 
utility meter provided at the location of the cardholder (item 10 in FIGS. 1-7, items 50, 60 in FIGS. 

4- 7), the utility meter being separate from the user interface unit and having an associated meter 
location identifier uniquely identifying the location of the utility meter (page 3 lines 5-6); and a 
financial institution remote from the user interface unit and utility meter (page 2 lines 2-4; item 40 
in FIGS. 2, 4-7). The utility meter is arranged to communicate with the user interface unit (page 3 
lines 6-7), to obtain the card charge data (page 3 lines 7-8), and to transmit card charge request 
including the card charge data and the meter location identifier to the financial institution (page 3 lines 
3-9). The financial institution is arranged to process the card charge request and, upon successful 
authorization, charge the credit / charge card as a card present type card charge (page 3 lines 11-21), 
regardless of whether the card charge request relates to any utility usage measurements made by the 
utility meter (page 3 lines 3-21). 

CLAIM 42 is directed to a financial transaction authorization system (page 3 lines 3-21) 
comprising: a user interface unit capable of accepting a credit / charge card transaction (page 4 lines 
1 8-23) ; a utility meter provided at a meter location (item 1 0 in FIGS .1-7, items 50, 60 in FIGS . 4-7) 
having an associated meter location identifier unique to the meter location (page 3 lines 5-6); and a 
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financial institution (page 2 lines 2-4; item 40 in FIGS . 2, 4-7) processing card charge requests (page 

2 lines 11-14, page 3 lines 8-9). Upon accepting a credit / charge card transaction at the user 
interface unit, one or both of the utility meter and user interface unit transmits a card charge request 
to the financial institution (page 3 lines 8-9), the card charge request encoding data representing: a 
credit / charge card account; an amount to be charged to the credit / charge card account; the 
presence of the credit / charge card at the location of the user interface unit; and the meter location 
identifier (page 3 lines 15-18, page 8 line 27 to page 9 line 5). The financial institution processes the 
card charge request regardless of whether the card charge request relates to any utility usage 
measurements made by the utility meter (page 3 lines 3-21). 

CLAIM 43 is directed to a transaction authorization system (page 3 lines 3-21) including: a 
utility meter provided at a meter location (item 1 0 in FIGS .1-7, items 50, 60 in FIGS . 4-7), the utility 
meter having an associated meter location identifier unique to the meter location (page 3 lines 5-6); 
and a user interface unit (item 30 in FIGS. 1-7) for accepting an authorization for a funds transfer 
(page 4 lines 19-21). The user interface unit includes a card reader device (item 35 in FIGS. 2, 4-7), 
the card reader device being arranged to read data from a credit / charge card to be charged for the 
funds transfer (page 4 lines 18-23). The user interface unit further communicates with the utility 
meter to obtain the location identifier (page 3 lines 6-8), and processes the data read from the credit 
/ charge card in combination with the location identifier to form at least a part of the funds transfer 
authorization to verify that the credit / charge card is physically present at the location of the utility 
meter (page 12 lines 20-27). The funds transfer authorization is unrelated to any utility usage (page 

3 lines 3-21). 
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CLAIM 45 is directed to a method of processing credit / charge card payments (page 3 lines 
3-21) including the steps of receiving a funds transfer authorization identifying a credit / charge card 
to be charged (page 3 lines 7-8), the funds transfer authorization including data uniquely identifying 
a location at which a utility meter is installed (page 3 lines 5-6), and being unrelated to any 
measurements made by the utility meter (page 3 lines 3-21). The method of claim 45 further includes 
the steps of accepting the data uniquely identifying the location as verifying that the credit / charge 
card is physically present at the location (page 3 lines 15-18, page 8 line 27 to page 9 line 3), and 
processing the funds transfer authorization as a card present type transaction (page 2 lines 11-14, 
page 3 lines 8-9). 

CLAIM 46 is directed to a credit / charge card transaction authorization system (page 3 lines 
3-21) including a utility meter situated at a meter location (item 10 in FIGS. 1-7, items 50, 60 in 
FIGS. 4-7), and having an associated meter location identifier which is unique to the meter location 
(page 3 lines 5-6). The system of claim 46 additionally includes a financial institution arranged to 
process submitted funds transfer requests for a credit / charge card (page 2 lines 2-4; item 40 in 
FIGS. 2, 4-7), the submitted funds transfer requests including card-present funds transfer requests 
wherein the physical location of the credit / charge card is verified, and card-not-present funds 
transfer requests wherein the physical location of the credit / charge card is not verified (page 3 lines 
15-18, page 8 line 27 to page 9 line 3). The card-not-present funds transfer requests are processed 
differently than card-present funds transfer requests (page 1 line 15 to page 2 line 5). The system of 
claim 46 further includes a user interface unit (item 30 in FIGS .1-7) configured to read data from the 
credit / charge card to be charged for the funds transfer (page 4 lines 18-23). The user interface unit 
is situated at the meter location, and is connected in communication with the utility meter (page 3 
lines 6-7). One or both of the user interface unit and the utility meter are configured to generate a 
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card-present funds transfer request for submission to the financial institution (page 3 lines 8-9), the 
submitted card-present funds transfer request having content encoding the data read from the credit 
/ charge card to be charged for the funds transfer, and the meter location identifier (page 3 lines 
15-18, page 8 line 27 to page 9 line 5). The card-present funds transfer request can verify that the 
credit / charge card is physically present at the meter location (page 3 lines 15-18, page 8 line 27 to 
page 9 line 3). The financial institution processes the submitted card-present funds transfer request 
regardless of whether the request relates to any utility usage measurements made by the utility meter 
(page 3 lines 3-21). 

CLAIM 47 is directed to a transaction payment method including the step of receiving a sales 
transaction (page 3 lines 3-21), wherein the sales transaction is unrelated to any utility usage (page 
3 lines 3-21). The method of claim 47 additionally includes the step of communicating data on the 
sales transaction to a user interface unit (page 3 lines 15-18, page 8 line 27 to page 9 line 3), the user 
interface unit (item 30 in FIGS. 1-7): being at a meter location (page 3 lines 1 1-21), being arranged 
to communicate with a utility meter at the meter location (page 3 lines 6-7), the utility meter having 
a meter location identifier uniquely identifying the meter location (page 3 lines 5-6); and having a 
card reader (item 35 in FIGS. 2, 4-7, page 4 lines 18-23). The method of claim 47 further includes 
the step of receiving, at the card reader, a credit / debit card to be charged for the sales transaction 
(page 3 lines 15-18, page 8 line 27 to page 9 line 3). The method of claim 47 furthermore includes 
the step of communicating a request to charge the credit / debit card for the transaction (page 3 lines 
8-9), the request including data regarding: the credit / debit card (page 3 lines 15-18, page 8 line 27 
to page 9 line 3); and the meter location identifier (page 3 lines 15-18, page 8 line 27 to page 9 line 
3). The request is independent of any utility usage data generated by the utility meter (page 3 lines 
3-21). 
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6, Grounds of Rejection to be Reviewed on Appeal (37 CFR §41.37(c)(l)(vi)) 

I. Whether claim 45 is directed to non-statutory subject matter under 35 USC §101. 

II. Whether claims 1-12, 14-21, 23, 28, 37-39, 41-43, and 45-47 are obvious under 35 
USC §103(a) in view of U.S. Patent 5,959,549 to Synesiou et al, U.S. Patent 5,146,067 to Sloan 
et al, and U.S. Patent 6,282,522 to Davis. 

HI. Whether claims 13, 24-26, and 48 are obvious under 35 USC § 103(a) in view of U.S. 
Patent 5,959,549 to Synesiou et al, U.S. Patent 5,146,067 to Sloan et al, U.S. Patent 6,282,522 to 
Davis, and WO 00/58922 to Bos. 

7. Argument (37 CFR §41.37(c)(l)(vii)) 

7.a. Rejection of Claim 45 under 35 USC §101 

This rejection is erroneous because the method recited by Claim 45 does in fact "transform 
a particular article into a different state or thing" in compliance with 35 USC §101. In claim 45, the 
utility meter data (clause a(l)) is effectively transformed into a "card-present" indication (clause b), 
which in turn triggers a card-present transaction (clause c). Stated differently, the claimed process 
begins with data representing utility meter location, and ends with a card-present verification which 
triggers a transaction. Neither the verification nor the transaction are present at the start of the 
method; these are effectively transformed / produced from the utility meter location data. In this 
respect, it is notable that In re Bilski, 88 USPQ2d 1385, 1397 (Fed. Cir. 2008) confirmed that 
transformation of data into a qualitatively different form could constitute a § 101-eligible 
"transformation," at least where the original data somehow represented features of a "physical and 
tangible object" (citing In re Abele, 214 USPQ 682 (CCPA 1982)). Claim 45 involves a 



-9- 



transformation of data representing a utility meter into different data (a card-present verification), as 
well as into an action (the card-present transaction), and is statutory. 

Further, the Supreme Court recently clarified in Bilski v. Kappos, 95 USPQ2d 1001, 1007 
(20 1 0) that the machine-or- transformation test is merely "a useful and important clue, an investigative 
tool, for determining whether some claimed inventions are processes under §101", and suggested that 
it may be more useful to determine whether the method in question is an "abstract idea," such as a 
mathematical formula or algorithm (Id. at 1009). Here, the claimed method is plainly not abstract: 
it cannot be performed solely mentally, and no mathematical formula or law of nature is preempted 
by the claimed method. 

7.b. Rejection of Claims 1-12. 14-21. 23. 28. 37-39. 41-43. and 45-47 under 35 USC §103(a) 

in view of U.S. Patent 5.959.549 to Svnesiou et al.. U.S. Patent 5.146.067 to Sloan et al.. 

and U.S. Patent 6.282.522 to Davis: Rejection of Claims 13. 24-26. and 48 under 35 

USC §103(a) further in view of WO 00/58922 to Bos 
7.b(l) Scope and Content of the Prior Art, and Differences from the Claimed Invention 

As noted in the Background section of the application, there are two primary types of card 
transactions known in the art: 

(1) Card-present transactions, wherein a purchaser physically presents the charge card to a vendor 
(such as a retail store) at a point of sale to pay for goods (page 1 lines 15-26 of the application). In 
this case, the vendor sees the card, and can visually inspect it (and perform actions such as matching 
the signature on the card to the signature provided by the purchaser) to acquire a reasonable 
assurance that the card is genuine and that the purchaser is authorized to use it. While fraud is still 
possible, card-present transactions pose a relatively low risk of fraud. 
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(2) Card-not-present transactions, wherein the purchaser is not at the physical point of sale, such 
as with sales made over the phone or via the Internet (page 1 lines 10-14, page 1 line 28-page 2 line 
16 of the application). In this case, the card cannot be inspected by the vendor. Instead, the card 
number is read over the phone or entered into a web page, and this is passed to an authorization 
authority (such as a financial institution) to obtain payment for the transaction. These transactions 
are more susceptible to fraud since they can be made without a card, and with stolen card data. 

From the perspective of the financial institution, the prospect of fraud is considerably higher 
for card-not-present transactions than for card-present transactions. As discussed at page 2 lines 18- 
32 of the application, this risk is reflected by the rates charged by financial institutions to merchants 
when accepting card-not-present transactions, by the time and level of scrutiny applied to 
card-not-present transactions, and by other hurdles faced by merchants accepting card-not-present 
transactions. 

U.S. Patent 5,959,549 to Synesiou et al. is then directed to an improved Electricity 
Dispensing Unit (EDU) system, wherein an EDU allows a consumer to prepay for power, and then 
cuts power to the site when the paid amount is consumed (column 1 lines 6-25). The communal 
metering controllers ("CMCs") 34 of FIG. 1 - which are effectively substations which subdistribute 
electricity from a mains cable 36 - are shown in greater detail in FIG. 2 to contain several remote 
measurement modules (meters) 38, which are in turn shown in greater detail in FIG. 3 (column 3 lines 
57-63). Each meter / remote measurement module 38 controls power supply to a particular site to 
which it is assigned (column 3 lines 57-63). Each meter / remote measurement module 38 measures 
the amount of power consumed at the meter / module 38's site, and passes the consumption data to 
the substation / CMC 34 of FIG. 2 (column 4 lines 4-24). Referring to column 4 lines 33-49, the 
meter /remote measurement module 3 8 also includes a controller 68 (FIG. 3) storing a variety of data 
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(column 4 lines 33-53), including "a unique identification number and a module address code, 
allowing the consumption data derived from a particular consumer site to be related to that site and 
to the credit data corresponding thereto" (column 4 lines 49-53). The controller 40 (FIG. 2) of the 
substation / CMC 34 then compares the consumption data and meter ID for each of its meters / 
modules 38 versus each meter / module 38's credit, and when the credit stored by the substation / 
CMC 34 is exhausted, the substation / CMC 34 signals the controller 68 (FIG. 3) of the meter / 
module 38 to cut the power (column 4 lines 54-67). 

A user prepays the provider for power (column 3 lines 26-32, column 5 lines 58-60), and the 
power purchase is relayed to the substation / CMC 34 (column 4 lines 54-59, column 5 lines 60-65). 
To collect prepayments, a display unit 73 (FIG. 4, column 5 lines 15-65) may be provided at each 
consumer site to collect credit card data along with a PIN for identifying the user (column 5 lines 
48-58). The display unit 73 is not part of the site's meter / module 38, nor does it communicate with 
the meter / module 38 (column 6 lines 40-43). Rather, the display unit 73 communicates any power 
purchase to the substation / CMC 34 (column 5 lines 1 5-24), which can in turn communicate a power 
purchase to the power provider (column 5 lines 48-65; see also column 3 lines 41-50 regarding 
transmissions between the provider and the substation / CMC 34). Regardless of how the payment 
is made, it is communicated to the substation / CMC 34 (column 5 lines 60-65), which (as noted 
above) then commands the user's meter / module 38 to cut power when the user's prepayment is 
exhausted (column 4 lines 54-67). 

In summary, Synesiou is solely dedicated to utility payments. It merely uses a meter ID to 
communicate power consumption data from the meter / module 38 to the substation / CMC 34, and 
to communicate power on/off commands from the substation / CMC 34 back to the meter / module 
38. If payment is made at the user interface / display 73, credit data is transmitted to the substation 



-12- 



/ CMC 34 and to the provider, but not to the meter / module 38, and without regard to the meter ID; 
rather, a PIN is used to identify the account being paid (column 5 lines 48-58). 1 

With regard to CLAIM 1, Synesiou' s utility meter 38 does not: communicate with user 
interface unit 73, as in clause a (the meter 38 only communicates with the substation / CMC 34); 
get a charge authorization from the user interface unit 73, as in clause b (the meter 38 does not 
receive anything from the user interface unit 73); or transmit a charge request to the financial 
institution based on the charge authorization and meter location ID, as in clause c (instead, the meter 
38 transmits consumption data to the substation / CMC 34), with the charge request including card 
account data as in clause c.(l) and card presence data as in clause c(2) (since the meter 38 does not 
handle charge requests). Further, contrary to the closing clause of claim 1, Synesiou only processes 
charge requests related to utility usage. 

With regard to CLAIM 28, Synesiou does not: communicate a charge authorization request 
from the user interface unit 73 to the utility meter 38 as in clause d (rather, the user interface unit 73 
only communicates any power purchase to the substation / CMC 34 and/or to the power provider); 
or transmit a message from the utility meter to a financial institution based on the charge 
authorization request and meter ID as in clause e (rather, the meter 38 only communicates power 
consumption to the substation / CMC 34). Further, contrary to the closing clause of claim 28, 
Synesiou only processes charge requests related to utility usage. 



1 In this respect, Synesiou is similar to current commonly known online payment systems wherein 
one enters a utility account number / customer number and card data to authorize payments for utility 
services. Since such systems do not tie card data to the ID of a nearby utility meter, payment can be 
made from a home computer, a work computer, or elsewhere, and the party processing the charge 
does not know from where the charge request originates. In contrast, the claimed system - which 
is intended for use for purchases of any goods or services - does help verify charge request location, 
and thus charge request validity. 
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With regard to CLAIM 37, Synesiou does not include a utility meter communicating with the 
user interface unit as in clause (1) (the meter 38 only communicates with the substation / CMC 34): 
to obtain the card charge data (the substation / CMC 34 gets charge data, not the meter 38), and to 
transmit card charge request including the card charge data and the meter location identifier to the 
financial institution (the meter 38 only communicates power consumption to the substation / CMC 
34). Further, contrary to the closing clause (2), Synesiou only processes charge requests related to 
utility usage. 

With regard to CLAIM 42, neither of Synesiou's utility meter 38 and user interface unit 73 
transmit a charge request to a financial institution (these only communicate with the substation / CMC 
34). Further, contrary to the closing clause, Synesiou only processes charge requests related to utility 
usage. 

With regard to CLAIM 43, Synesiou does not include a user interface unit communicating 
with the utility meter to obtain the meter location identifier as in clause b(2) (Synesiou' s user 
interface unit 73 does not communicate with utility meter 38, and only communicates with the 
substation / CMC 34 and/or the power provider), nor does it process the credit/charge card data in 
combination with the meter location identifier to verify that the credit/charge card is physically 
present at the location of the utility meter (rather, the user interface unit 73 only communicates any 
power purchase to the substation / CMC 34 and/or to the power provider). Further, contrary to the 
closing clause, Synesiou only processes charge requests related to utility usage. 

With regard to CLAIM 45, Synesiou does not include, in the course of a funds transfer 
authorization, accepting meter location data as verifying card presence at the meter location as in 
clause b, and processing the funds transfer authorization as a card present type transaction as in 
clause c. 



-14- 



With regard to CLAIM 46, Synesiou does not include a user interface unit connected in 
communication with the utility meter as in clause c(3) and the clauses thereafter. 

With regard to CLAIM 47, Synesiou does not include a user interface unit arranged to 
communicate with a utility meter as in clause b(2) (Synesiou' s user interface unit 73 does not 
communicate with utility meter 38, and only communicates with the substation / CMC 34 and/or the 
power provider). Further, contrary to the closing clause, Synesiou only processes charge requests 
related to utility usage. 

U.S. Patent 5,146,067 to Sloan etal. concerns a prepayment utility metering system in which 
cards are loaded with pre-payment credits at a location remote from the utility meter (column 3 lines 
5 1-60), and the cards can then be read at the meter to provide utility credits (i.e., to prepay for utility 
usage). When the credits are exhausted, a new card with additional credits must be purchased to 
ensure continued utility supply (column 17 lines 35 to 39). The cards are not credit or debit cards, 
nor could they be used as such. The data on the cards, which is borne on a magnetic strip, is 
encrypted for security so that only the issuing system and the customer's premises can read the data 
(column 3 lines 60-65). The utility meter does not communicate with the utility supplier concerning 
a financial transaction (the utility usage purchase); it has no need to do so, since the utility meter 
simply stops supplying the utility once the pre-paid credits are exhausted. The cards are only sold 
to consumers at certain facilities (column 8 lines 32-35), and the underlying financial transaction will 
take place at these facilities when purchasing the prepayment credits. The transaction type will 
depend on whether the transaction meets the credit/debit card present criteria and has nothing to do 
with the use of the card (this is what is being bought). 

All the utility meter needs to do in Sloan is read the data on the card. The utility meter and/or 
its user interface does not communicate any data away from the meter (to a financial institution or 
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otherwise); it simply turns the meter on and off in relation to the credit detected on the card. Sloan 
does not address any of the deficiencies of Synesiou with respect to the claims, and the Office Action 
cites (or at least seems to cite) Sloan solely because it uses a card reader at the meter, and thereby 
has a user interface at the meter which indicates card presence. 

U.S. Patent 6,282,522 to Davis et al. is simply an internet-based purchasing scheme wherein 
a user purchases goods or services over the internet using a stored-value card read at a card reader 
associated with the user's computer (Abstract, column 6 line 23-column 7 line 25, column 12 lines 
10-22, FIG. 10). Davis et al. does not address any of the deficiencies of Synesiou with respect to the 
claims, and the Office Action cites (or at least seems to cite) Davis et al. solely because it processes 
all charge requests regardless of whether they relate to any utility usage measurements. 

WO 00/58922 to Bos is then yet another system for purchasing utility usage by a prepayment 
system, but here the prepayment credit or "token" is purchased wirelessly (via a cellular / GSM 
handset), thereby avoiding the need for a rural customer to go to a location which sells prepayment 
cards (as in Sloan et al.). The utility meter does not take any part in the actual purchase of the 
prepayment token; this is purely between the customer's cellular / GSM handset and the token 
vending site. As such, it is not clear Bos even uses credit / charge card transactions, and in any event 
it certainly would not be the case that the utility meter could be used to vouch for the location of the 
transaction (given that it could happen anywhere from which one is capable of making a GSM call). 
Bos does not address any of the deficiencies of Synesiou with respect to the claims, and the Office 
Action cites (or at least seems to cite) Bos solely because it uses a telephone as a "user interface unit" 
for making purchases. 
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7.b(2) Unobviousness of the Claimed Invention 



As briefly summarized in the foregoing Section 5 of this brief, the claimed invention is directed 
to systems and methods for reducing credit / debit fraud by verifying, in the course of a purchase or 
other transaction, that the charge card is present at or near the location of a specific utility meter. The 
claimed invention alleviates the risks associated with card-not-present transactions, at least in part, 
by tying the card number (and card presence data, such as a physical card swipe and/or entry of the 
three-digit code on the card signature strip 2 ) to the unique identifier (and thus the location) of a utility 
meter to verify the purchaser's (and the card's) physical location. It can therefore be known whether 
a charge originates from a "safe" location — e.g., the authorized user's residence, or a nearby store 
- rather than an unsafe one, e.g., a far-off location at which the authorized user is unlikely to be. 

Looking to the stated rationale for the rejections at pages 5-6 of the April 6, 2010, Office 
Action (and repeated at page 7 of that Office Action): 

In this case, each of the elements of the cited references combined by the Examiner 
performs the same function when combined as it does in the prior art. Thus, such a 
combination would have yielded predictable results. See Sakraida, 425 U.S. at 282, 189 
USPQ at 453. Therefore, Supreme Court Decision in KSR International Co. v. Teleflex Inc. 
(KSR, 82 USPQ2d at 1396) forecloses the argument that a specific teaching, suggestion, or 
motivation is required to support a finding of obviousness. See the recent Board decision Ex 
parte Smith, ~USPQ2d~, slip op. at 20, (Bd. Pat. App. & Interf. lune 25, 2007) 

Therefore, it would have been obvious to one having ordinary skill in the art at the 
time the invention was made to modify Synesiou and Sloan to include that the financial 
institution processes the card charge request from the utility meter regardless of whether the 
card charge request relates to any utility usage measurements, since the claimed invention is 
merely a combination of old elements, and in the combination each element merely would have 
performed the same function as it did separately, and one of ordinary skill in the art would 
have recognized that the results of the combination were predictable. KSR, 111 S.Ct. at 1740, 
82 USPQ2dat 1396. 



2 This code is variously referred to in the industry as the Card Security Code (CSC), Card 
Verification Value (CVV), Card Verification Code (CVC), Card Code Verification (CCV), 
Verification Code (V-Code), and similar names. It is noted that the USPTO' s own EFS-Web online 
filing system requests such codes if charge cards are used to pay USPTO fees online. 
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This reasoning is incorrect. Firstly, it is clearly incorrect to state that "in the [claimed] 
combination each element merely would have performed the same function as it did separately": as 
noted above, there are several features of the claimed combination which are not present in Synesiou 
or in the other references, and which have functions that are not present in the prior art references. 
More generally, no art of record shows use of utility meter data to function as an indicator of card 
location/presence. None of the foregoing references show transactions, and in particular non-utility 
transactions, wherein the transaction data transmitted to a financial institution includes, encodes, or 
is dependent on a meter ID, in particular where the meter ID is used to verify card presence (e.g., is 
used in combination with card-presence data such as a CVV code). This notion is not known in the 
prior art, nor is it foreseeable in view of the art, and reflects a significant innovation in fraud 
deterrence methods. It is therefore incorrect to hold that "the claimed invention is merely a 
combination of old elements, and in the combination each element merely would have performed the 
same function as it did separately." 

Secondly, the reasoning underlying the rejections is conclusory, and merely recites passages 

of prior cases rather than explaining why the invention, as particularly claimed, would be foreseeable 

(and thus obvious) by an ordinary artisan after review of the particular references of record. From 

the Ex parte Smith case cited by the Office Action: 

The [KSR] Court explained, "[o]ften, it will be necessary for a court to look to interrelated 
teachings of multiple patents; the effects of demands known to the design community or 
present in the marketplace; and the background knowledge possessed by a person having 
ordinary skill in the art, all in order to determine whether there was an apparent reason to 
combine the known elements in the fashion claimed by the patent at issue ." Id. at 1740-41, 
82 USPQ2d at 1396. The Court noted that "ftlo facilitate review, this analysis should be 
made explicit." Id., citing In re Kahn, 441 F.3d 977, 988, 78 USPQ2d 1329, 1336 (Fed. Cir. 
2006) C TR1 ejections on obviousness grounds cannot be sustained by mere conclusory 
statements; instead, there must be some articulated reasoning with some rational underpinning 
to support the legal conclusion of obviousness "'). 
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Ex Parte Smith at 14 (emphasis added). More recent cases of the Board of Appeals have gone even 



further to explain that conclusory reasoning is insufficient, and any rejections must be supported by 
case-specific reasoning. From Ex parte Whalen, 89 USPQ2d 1078, 1084 (Bd. Pat. App. &Int. 2008): 

The U.S. Supreme Court recently held that rigid and mandatory application of the 
"teaching-suggestion-motivation," or TSM, test is incompatible with its precedents. KSR Int'l 
Co. v. Teleflexlnc, 127 S.Ct. 1727, 1741 [82 USPQ2d 1385] (2007). The Court did not, 
however, discard the TSM test completely; it noted that its precedents show that an invention 
"composed of several elements is not proved obvious merely by demonstrating that each of its 
elements was, independently, known in the prior art." Id. 

The Court held that the TSM test must be applied flexibly, and take into account a 
number of factors "in order to determine whether there was an apparent reason to combine the 
known elements in the fashion claimed. " Id. at 1740-41 . Despite this flexibility, however, the 
Court stated that "it can be important to identify a reason that would have prompted a person 
of ordinary skill in the relevant field to combine the fprior art! elements in the way the claimed 
new invention does." Id. "To facilitate review, this analysis should be made explicit." Id. . . 

The KSR Court noted that obviousness cannot be proven merely by showing that the 
elements of a claimed device were known in the prior art; it must be shown that those of 
ordinary skill in the art would have had some "apparent reason to combine the known elements 
in the fashion claimed." Id. at 1741. 



(Emphasis added.) See also MPEP 2143.01, part IV (noting that the mere fact that "the references 
relied upon teach that all aspects of the claimed invention were individually known in the art is not 
sufficient to establish a prima facie case of obviousness without some objective reason to combine 
the teachings of the references.") 

The stated bases for the rejections are the type of "mere conclusory statements" prohibited 
by the foregoing decisions, and contain no "articulated reasoning with some rational underpinning to 
support the legal conclusion of obviousness" (as required by the foregoing decisions): they simply 
regurgitate form paragraphs to justify the conclusion of obviousness. More particularly, the rejections 
do not explain any "apparent reason to combine the known elements in the fashion claimed" (as also 
required by the foregoing decisions), and rather the rejections find that the invention is obvious 
because the "claimed invention is merely a combination of old elements" - which, as noted by the 
foregoing cases, is not a sufficient basis for declaring the claimed invention obvious. Even if we 



assume for the sake of argument that the "claimed invention is merely a combination of old elements, 

and in the combination each element merely would have performed the same function as it did 

separately" (which is not in fact the case, as explained above), what is the "apparent reason to 

combine the known elements in the fashion claimed"? The Applicants submit that there is no 

apparent reason - that one reviewing the art of record would never have contemplated the claimed 

invention. Traditionally, processors of card charge authorizations (e.g., banks and card transaction 

clearinghouses) do not include any mechanism for verifying, in a fraud-resistant manner, from where 

a charge request arises. No solution for this problem is apparent from the art of record. Looking 

then to the field of utility transactions (e.g., Synesiou, Sloan, Bos, and the like), this issue is similarly 

not addressed - nor is there any need to, since fraudulent utilities transactions aren' t a concern (since 

even if a payment authorization is fraudulent, the utility provider knows where the utility is being 

delivered to). 3 Prior to the Applicants ' invention, there was simply no basis for others to conceive 

the notion of tying card data to a meter ID when submitting a card charge authorization so that the 

location of the authorization could be identified via the location of the identified meter. The 

invention is unobvious, and reflects a significant development in fraud prevention. 

In summary, keeping in mind the obviousness analysis mandated by MPEP 2142: 

To reach a proper determination under 35 U.S.C. 103, the examiner must step backward in 
time and into the shoes worn by the hypothetical "person of ordinary skill in the art" when the 
invention was unknown and just before it was made. In view of all factual information, the 
examiner must then make a determination whether the claimed invention "as a whole" would 
have been obvious at that time to that person. Knowledge of applicant's disclosure must be 
put aside in reaching this determination, yet kept in mind in order to determine the 
"differences," conduct the search and evaluate the "subject matter as a whole" of the 
invention. The tendency to resort to "hindsight" based upon applicant's disclosure is often 



3 Further, even if it was assumed for the sake of argument that utility transaction systems such 
as Synesiou, Sloan, Bos, and the like did somehow verify the location of a consumer's card charge 
authorization, it cannot reasonably be said that the ordinary artisan would contemplate opening such 
systems to non-utility payments, as it does not seem that utility providers have the "bandwidth" or 
desire to handle any payments beyond those affecting their own services. 
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difficult to avoid due to the very nature of the examination process. However, impermissible 
hindsight must be avoided and the legal conclusion must be reached on the basis of the facts 
gleaned from the prior art. 

We submit that an ordinary artisan who had no knowledge of the claimed invention, but who knew 
the general state of the art (including the cited references), would not truly come to conceive the 
claimed invention in light of this knowledge. Further, the Office Action contains no "articulated 
reasoning" explaining a contrary conclusion. Kindly withdraw the rejections. 



8. In Closing 

For the reasons presented above, the Board is requested to reverse the rejections and to allow 
claims 1-21, 23-26, 28, 37-39, 41-43, and 45-48. 

If any questions regarding the application arise, please contact the undersigned attorney. 
Telephone calls related to this application are welcomed and encouraged. 

The Commissioner is authorized to charge any fees or credit any overpayments relating to this 
appeal to deposit account number 18-2055. 

For the Applicant / Appellant, 

Craig A. Fieschko, Reg. No. 39,668 

CUSTOMER NO. 25005 
DEWITT ROSS & STEVENS S.C. 
2 E. Mifflin St., Suite 600 
Madison, WI 53703-2865 
Telephone: (608) 395-6722 
Facsimile: (608) 252-9243 
cf@dewittross.com 
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CLAIMS APPENDIX 
1 . (PREVIOUSLY PRESENTED) A financial transaction authorization system comprising: 

A. a financial institution which processes credit/charge card charge requests, 

B. a utility meter provided at a meter location separate and spaced from the financial 
institution, the utility meter having an associated meter location identifier unique to 
the meter location, and 

C. a user interface unit separate and spaced from the financial institution, the user 
interface unit being adapted to process a submitted credit/charge card charge 
authorization, 

wherein the utility meter is arranged: 

a. to communicate with the user interface unit, 

b. to obtain the card charge authorization therefrom, and 

c . to transmit a credit/charge card charge request to the financial institution based on the 
card charge authorization and meter location identifier, the card charge request 
including: 

(1) data identifying a credit/charge card account, and 

(2) data verifying that the credit/charge card corresponding to the credit/charge 
card account is physically present at the location of the user interface unit, 

to obtain authorization of the card charge from the financial institution, wherein the financial 
institution processes the card charge request from the utility meter regardless of whether the 
card charge request relates to any utility usage measurements made by the utility meter. 
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2. (PREVIOUSLY PRESENTED) A financial transaction authorization system according to 
claim 1 , further comprising a communication unit arranged to communicate with the financial 
institution, wherein the utility meter is arranged to submit the card charge request to the 
communication unit for communication to the financial institution to obtain authorization of 
the card charge. 

3 . (PREVIOUSLY PRESENTED) A financial transaction authorization system according to 
claim 2, in which the utility meter is arranged to submit utility usage data to the 
communication unit. 

4. (PREVIOUSLY PRESENTED) A financial transaction authorization system according to 
claim 2, wherein the utility meter provided at the location is a first utility meter, and further 
comprising a second utility meter provided at the location, wherein said second utility meter 
is arranged to submit utility usage data to the communication unit. 

5 . (PREVIOUSLY PRESENTED) A financial transaction authorization system according to 
claim 4, in which said second utility meter is arranged to submit the utility usage data to said 
first utility meter for submission to the communication unit. 

6. (PREVIOUSLY PRESENTED) A financial transaction authorization system according to 
claim 4, in which said second meter is a gas or water meter. 
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7. 



(PREVIOUSLY PRESENTED) A financial transaction authorization system according to 
claim 1, in which the utility meter is an electricity meter. 



8 . (PREVIOUSLY PRESENTED) A financial transaction authorization system according to 
claim 3, in which the communication unit is arranged to communicate utility usage data to a 
utility supplier. 

9 . (PREVIOUSLY PRESENTED) A financial transaction authorization system according to 
claim 3, in which the communication unit communicates with one or more utility suppliers via 
a central control system. 

10. (PREVIOUSLY PRESENTED) A financial transaction authorization system according to 
claim 2, in which the financial institution comprises a central control system, wherein the 
central control system processes received card charge requests and submits the requests to 
appropriate banking authorities for fulfilment. 

1 1 . (PREVIOUSLY PRESENTED) A financial transaction authorization system according to 
claim 2, in which the communication unit is a modem. 

12. (PREVIOUSLY PRESENTED) A financial transaction authorization system according to 
claim 2, in which the user interface unit is the communication unit. 
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1 3 . (PREVIOUSLY PRESENTED) A financial transaction authorization system according to 
claim 12, wherein the user interface unit is a telephone. 

14. (PREVIOUSLY PRESENTED) A financial transaction authorization system according to 
claim 4, in which the user interface unit and the utility meter communicate with each other via 
RF signals. 

1 5 . (PREVIOUSLY PRESENTED) A financial transaction authorization system according to 
claim 4, in which the communication unit and the utility meter communicate with each other 
via RF signals. 

16. (PREVIOUSLY PRESENTED) A financial transaction authorization system according to 
claim 6, in which the further utility meter communicates via RF signals. 

17. (PREVIOUSLY PRESENTED) A financial transaction authorization system according to 
claim 2, in which the user interface unit includes a card reader device, wherein the card reader 
device is arranged to read data from a credit/charge card to be charged, the user interface unit 
processing the data read from the credit/charge card to form at least a part of a card charge 
authorization. 
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1 8 . (PREVIOUSLY PRESENTED) A financial transaction authorization system according to 
claim 3, in which the user interface unit includes a keyboard, wherein the user interface unit 
is arranged to accept data entered via the keyboard to form at least a part of a card charge 
authorization. 

1 9 . (PREVIOUSLY PRESENTED) A financial transaction authorization system according to 
claim 3, in which the utility meter includes a memory for storing a user's banking data, 
wherein the user interface unit is arranged to accept an input from the user authorizing use 
of at least part of the banking data, the utility meter then using the at least part of the banking 
data to form at least a part of a card charge authorization. 

20. (PREVIOUSLY PRESENTED) A financial transaction authorization system according to 
claim 3, in which the user interface unit includes a display, wherein the user interface unit is 
arranged to display on request utility usage data from the utility meter. 

2 1 . (PREVIOUSLY PRESENTED) A financial transaction authorization system according to 
claim 3, in which the user interface unit is connectable to a computer, wherein the user 
interface unit, when connected to a computer, is operative to make necessary card charge 
authorization requests in response to electronic transactions initiated on the computer. 

22. (CANCELED) 
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23. 



(PREVIOUSLY PRESENTED) A financial transaction authorization system according to 
claim 3, in which the user interface device is remote from the utility meter. 



24. (PREVIOUSLY PRESENTED) A financial transaction authorization system according to 
claim 4, further comprising a digital cellular transceiver arranged to communicate with the 
utility meter for transmitting data to, and receiving data, from a remote source. 

25 . (PREVIOUSLY PRESENTED) A financial transaction authorization system according to 
claim 24, in which the transceiver is the communication unit. 

26. (PREVIOUSLY PRESENTED) A financial transaction authorization system according to 
claim 24, further comprising a switching unit controllable by the utility meter for switching 
one or more appliances on or off, wherein when the utility meter receives a signal via the 
transceiver indicating the availability of cheap-rate energy it is arranged to control the 
switching unit to switch appliances on. 

27. (CANCELED) 
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28. (PREVIOUSLY PRESENTED) A method of authorizing a card financial transaction 
comprising the steps of: 

a. providing a user interface unit at a location; 

b. providing a utility meter at the location, the utility meter having an associated meter 
location identifier uniquely identifying the location; 

c. accepting a card charge authorization request via the user interface unit, the 
transaction authorization request including: 

(1) data verifying that a credit/charge card is present at the location of the user 
interface unit, and 

(2) data identifying the credit/charge card account of the credit/charge card; 

d. communicating the card charge authorization request from the user interface unit to 
the utility meter; and 

e. transmitting a message generated in dependence on the card charge authorization 
request and meter location identifier from the utility meter to a financial institution to 
obtain authorization of the card charge, wherein the financial institution processes the 
message regardless of whether it relates to any utility usage measurements made by 
the utility meter. 



29-36. (CANCELED) 
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37. (PREVIOUSLY PRESENTED) A credit/charge card financial transaction authorization 
system for card charge transactions where the cardholder is at a location remote from the 
vendor, the system comprising: 

a. a user interface unit capable of accepting card charge data including: 

(1) credit/charge card data identifying a credit/charge card to be charged, and 

(2) data verifying that the credit/charge card is physically present at the user 
interface unit; and, 

b. a utility meter provided at the location of the cardholder, the utility meter being 
separate from the user interface unit and having an associated meter location identifier 
uniquely identifying the location of the utility meter, 

c. a financial institution remote from the user interface unit and utility meter, 
wherein: 

( 1 ) the utility meter is arranged to communicate with the user interface unit, to obtain the 
card charge data, and to transmit card charge request including the card charge data 
and the meter location identifier to the financial institution; 

(2) the financial institution is arranged to process the card charge request and, upon 
successful authorization, charge the credit/charge card as a card present type card 
charge, regardless of whether the card charge request relates to any utility usage 
measurements made by the utility meter. 

38. (PREVIOUSLY PRESENTED) A financial transaction authorization system according to 
claim 1, wherein the card charge authorization, card charge request, and corresponding card 
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charge are independent of any utility usage data generated by the utility meter, whereby the 
card charge does not pay for any utility usage measured by the utility meter. 



39. (PREVIOUSLY PRESENTED) The method of claim 28 wherein the card charge 
authorization request and corresponding card charge are independent of any utility usage data 
generated by the utility meter, whereby the card charge does not pay for any utility usage 
measured by the utility meter. 



40. (CANCELED) 



4 1 . (PREVIOUSLY PRESENTED) The credit/charge card financial transaction authorization 
system of claim 37 wherein the card charge data are independent of any utility usage data 
generated by the utility meter, whereby the card charge does not pay for any utility usage 
measured by the utility meter. 



A-9 



(PREVIOUSLY PRESENTED) A financial transaction authorization system comprising: 

A. a user interface unit capable of accepting a credit/charge card transaction, and 

B. a utility meter provided at a meter location having an associated meter location 
identifier unique to the meter location, and 

C. a financial institution processing card charge requests, 

wherein upon accepting a credit/charge card transaction at the user interface unit, one or both 
of the utility meter and user interface unit transmits a card charge request to the financial 
institution, the card charge request encoding data representing: 

(1) a credit/charge card account, 

(2) an amount to be charged to the credit/charge card account, 

(3) the presence of the credit/charge card at the location of the user interface unit, and 

(4) the meter location identifier, 

wherein the financial institution processes the card charge request regardless of whether the 
card charge request relates to any utility usage measurements made by the utility meter. 
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43. (PREVIOUSLY PRESENTED) A transaction authorization system including: 

a. a utility meter provided at a meter location, the utility meter having an associated 
meter location identifier unique to the meter location, 

b. a user interface unit for accepting an authorization for a funds transfer, the user 
interface unit: 

( 1 ) including a card reader device, the card reader device being arranged to read 
data from a credit/charge card to be charged for the funds transfer, 

(2) communicating with the utility meter to obtain the location identifier, 

(3) processing the data read from the credit/charge card in combination with the 
location identifier to form at least a part of the funds transfer authorization to 
verify that the credit/charge card is physically present at the location of the 
utility meter, 

wherein the funds transfer authorization is unrelated to any utility usage. 



44. (CANCELED) 
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(PREVIOUSLY PRESENTED) A method of processing credit/charge card payments 
including the steps of: 

a. receiving a funds transfer authorization identifying a credit/charge card to be charged, 
the funds transfer authorization: 

(1) including data uniquely identifying a location at which a utility meter is 
installed, and 

(2) being unrelated to any measurements made by the utility meter; 

b . accepting the data uniquely identifying the location as verifying that the credit/charge 
card is physically present at the location, and 

c. processing the funds transfer authorization as a card present type transaction. 



(PREVIOUSLY PRESENTED) A credit/charge card transaction authorization system 
including: 

a. a utility meter: 

(1) situated at a meter location, and 

(2) having an associated meter location identifier which is unique to the meter 
location; 

b. a financial institution arranged to process submitted funds transfer requests for a 
credit / charge card, the submitted funds transfer requests including: 

(1) card-present funds transfer requests wherein the physical location of the 
credit/charge card is verified, 

(2) card-not-present funds transfer requests wherein the physical location of the 
credit/charge card is not verified; 

wherein card-not-present funds transfer requests are processed differently than 
card-present funds transfer requests; 

c. a user interface unit: 

(1) configured to read data from the credit/charge card to be charged for the 
funds transfer; 

(2) being situated at the meter location, and 

(3) being connected in communication with the utility meter, 

wherein one or both of the user interface unit and the utility meter are configured to generate 
a card-present funds transfer request for submission to the financial institution, the submitted 
card-present funds transfer request having content encoding: 

I. the data read from the credit/charge card to be charged for the funds transfer, and 
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II. the meter location identifier, 

whereby the card-present funds transfer request verifies that the credit/charge card is 
physically present at the meter location, and 

wherein the financial institution processes the submitted card-present funds transfer request 
regardles s of whether the request relates to any utility usage measurements made by the utility 
meter. 
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47. (PREVIOUSLY PRESENTED) A transaction payment method including the steps of: 

a. receiving a sales transaction, wherein the sales transaction is unrelated to any utility 
usage; 

b. communicating data on the sales transaction to a user interface unit, the user interface 
unit: 

(1) being at a meter location, 

(2) being arranged to communicate with a utility meter at the meter location, the 
utility meter having a meter location identifier uniquely identifying the meter 
location, and 

(3) having a card reader; 

c. receiving, at the card reader, a credit/debit card to be charged for the sales 
transaction; and 

d. communicating a request to charge the credit/debit card for the transaction, the 
request including data regarding: 

(1) the credit/debit card, and 

(2) the meter location identifier, 

wherein the request is independent of any utility usage data generated by the utility 
meter. 

48 . (PREVIOUSLY PRESENTED) The transaction payment method of claim 47 wherein the 
sales transaction is received via on-line or telephonic communication. 
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